4.1.1.  OGC SensorThings API

The OGC SensorThings API Standard provides an open and harmonized way to interconnect devices, data, and applications over the web and on the Internet of Things (IoT). At a high level the OGC SensorThings API provides two main parts, namely Part I — Sensing, and Part II — Tasking. The Sensing part provides a standard way to manage and retrieve observations and metadata from a variety of IoT sensor systems. The Tasking part provides a standard way for tasking IoT devices, such as sensors or actuators. The SensorThings API follows REST principles and uses JSON for encoding messages, as well as MQTT for publish/subscribe operations.

4.1.2.  OGC STAplus — an extension of the OGC SensorThings API

STAplus is an extension to the OGC SensorThings data model. Inspired by Citizen Science applications, STAplus supports the ‘ownership concept’ whereby observations collected by sensors are owned by (different) users that may express the license for re-use. In addition to the ownership and license abilities, the extension specified by STAplus supports the expression of explicit relations between observations and the creation of group(s) of observations.

4.1.3.  OGC API — Features

The OGC API — Features Standard offers the capability to create, modify, and query spatial data on the Web. The Standard specifies requirements and recommendations for APIs that want to follow a standard way of sharing feature data. The specification is a multi-part standard. Part 1, labelled the Core, describes the mandatory capabilities that every implementing service has to support and is restricted to read-access to spatial data that is referenced to the World Geodetic System 1984 (WGS 84) Coordinate Reference System (CRS). Part 2 enables the use of different CRS, in addition to the WGS 84. Additional capabilities that address specific needs will be specified in additional parts. Envisaged future capabilities include, for example, support for creating and modifying data, more complex data models, and richer queries.

The OGC API — Features Standard is part of the OGC API family of standards. OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. The standards make use of the OpenAPI specification for defining the API building blocks.

4.1.4.  OGC API — Tiles

OGC API — Tiles specifies a Standard for Web APIs that provide tiles of geospatial information. The Standard supports different forms of geospatial information, such as tiles of vector features (“vector tiles”), coverages, maps (or imagery) and potentially eventually additional types of tiles of geospatial information.

Vector data represents geospatial objects such as points, lines, and polygons. Tiles of vector feature data (i.e., Vector Tiles) represent partitions of vector data covering a large area (e.g., lines representing rivers in a country).

In this context, a map is essentially an image representing at least one type of geospatial information. Tiles of maps (i.e., Map Tiles) represent subsets of maps covering a large area (e.g., a satellite image).

4.1.5.  OGC API — Coverages

The OGC API — Coverages candidate standard establishes an access mechanism for coverages as defined by the OGC Abstract Specification Topic 6 / ISO 19123 Schema for coverage geometry and functions through a Web API which can be described by an API description language such as the OpenAPI specification. Arguably the most popular type of coverage is that of a gridded coverage. Gridded coverages have a grid as their domain set describing the direct positions in multi-dimensional coordinate space, depending on the type of grid. Satellite imagery is typically modeled as a gridded coverage, for example.

4.1.6.  OGC API — Environmental Data Retrieval

The OGC API — Environmental Data Retrieval (EDR) Standard API provides a family of lightweight interfaces to access Environmental Data resources. Each resource addressed by an EDR API maps to a defined query pattern. This specification identifies resources, captures compliance classes, and specifies requirements which are applicable to OGC Environmental Data Retrieval API’s. This specification addresses two fundamental operations; discovery and query. Discovery operations allow the API to be interrogated to determine its capabilities and retrieve information (metadata) about this distribution of a resource. This includes the API definition of the server as well as metadata about the Environmental Data resources provided by the server. Query operations allow Environmental Data resources to be retrieved from the underlying data store based upon simple selection criteria, defined by this standard and selected by the client.

Recently, the EDR SWG has commenced work on EDR Part 2: Publish-Subscribe workflow.

4.1.7.  OGC GeoPose

OGC GeoPose is a standard for exchanging the location and orientation of real or virtual geometric objects (Poses) within reference frames anchored to the earth’s surface (Geo) or within other astronomical coordinate systems. GeoPose specifies a single encoding in JSON format (IETF RFC 8259). The use cases addressed by GeoPose involve interactions between information systems or between an information system and a storage medium. The role of a GeoPose is to convey the orientation and position of a real or virtual object.

4.2.1.  Model for Underground Data Definition and Integration (MUDDI)

The MUDDI candidate standard serves as a framework to make datasets that utilize different information for underground objects interoperable, exchangeable, and more easily manageable.

The MUDDI Conceptual Model represents real-world objects found underground. It was designed as a common basis to create implementations that make different types of subsurface data — such as those relating to utilities, transport infrastructure, soils, ground water, or environmental parameters — interoperable in support of a variety of use cases and in different jurisdictions and user communities.

4.2.2.  OGC API — Records

The OGC API — Records candidate Standard provides discovery and access to metadata records about resources such as features, coverages, tiles / maps, models, assets, services or widgets. The candidate Standard enables the discovery of geospatial resources by standardizing the way collections of descriptive information about the resources (metadata) are exposed. The candidate Standard also enables the discovery and sharing of related resources that may be referenced from geospatial resources or their metadata by standardizing the way all kinds of records are exposed and managed.

4.2.3.  OGC Publish/Subscribe extension of OGC API Standards

OGC APIs provide Web based capabilities which are typically based on polling for collection resource updates (new features/records items, coverages, maps, etc.). Depending on a collection’s temporal resolution or frequency of updates, an event-driven / Publish-Subscribe architecture provides a time, efficient and low latency approach for delivery of data updates.

4.3.1.  NGIIS GIMI

TBA

4.3.2.  AsyncAPI

AsyncAPI is a specification by the Linux Foundation for describing and documenting message-driven APIs in a machine-readable and protocol-agnostic format. The specification defines a set of files required to describe a message-driven API. The files describing an API in accordance with the AsyncAPI Specification may be encoded in JSON or YAML.

4.4.1.  OSGeo GeoNetwork

GeoNetwork is a catalog application for managing spatially referenced resources. It provides metadata editing and search functions as well as an interactive web map viewer.

4.4.2.  geo-heif-viewer

Then geo-heif-viewer is a proof-of-concept viewer for HEIF files containing geographical data (according to the GIMI profile), e.g. satellite imagery.

This viewer uses custom-built versions of:

• mp4box https://github.com/gpac/mp4box.js/ (BSD-3 license)

• vidterra’s misb.js https://github.com/vidterra/misb.js/ (MIT license)

…​as well as an unmodified copy of:

• heic2any https://github.com/alexcorvi/heic2any (MIT license)

4.4.3.  OSGeo pygeoapi

pygeoapi is a Python server implementation of the OGC API suite of Standards. The project emerged as part of the next generation OGC API efforts in 2018 and provides the capability for organizations to deploy a RESTful OGC API endpoint using OpenAPI, GeoJSON, and HTML. pygeoapi is open source and released under an MIT license. pygeoapi is an official OSGeo Project as well as an OGC Reference Implementation.

pygeoapi supports numerous OGC API Standards. The official documentation provides an overview of all supported standards.

4.4.4.  OSGeo pycsw

pycsw is an implementation of OGC API — Records and the OGC’s Catalogue Service for the Web (CSW) written in Python. Started in 2010 (more formally announced in 2011), pycsw allows for the publishing and discovery of geospatial metadata via numerous APIs (CSW 2/CSW 3, OpenSearch, OAI-PMH, SRU), providing a standards-based metadata and catalogue component of spatial data infrastructures. pycsw is Open Source, released under an MIT license, and runs on all major platforms (Windows, Linux, Mac OS X). pycsw is an official OSGeo Project as well as an OGC Reference Implementation.

pycsw supports numerous metadata content and API standards, including OGC API — Records — Part 1.0: Core and its associated specifications. The official documentation provides an overview of all supported standards.

4.4.5.  ldproxy

ldproxy is an implementation of the OGC API family of standards, available under the MPL 2.0 open source license. ldproxy is developed by interactive instruments GmbH, written in Java, and is deployed using Docker containers. ldproxy implements all parts of OGC API — Features, OGC API — Tiles, OGC API — Styles, OGC API — 3D GeoVolumes, and OGC API — Routes. It is an OGC Reference Implementation for Parts 1 and 2 of OGC API — Features.

4.4.6.  MariaDB CubeWerx CubeServ

The CubeWerx server (“cubeserv”) is implemented in C and currently implements the following OGC Standards and draft specifications.

• Multiple conformance classes and recommendations of the OGC API — Tiles — Part 1: Core Standard.

• Multiple conformance classes and recommendations of the OGC API — Maps — Part 1: Core candidate Standard.

• All conformance classes and recommendations of the OGC API — Features — Part 1: Core Standard.

• Multiple conformance classes and recommendations of the OGC API — Records — Part 1: Core candidate Standard.

• Multiple conformance classes and recommendations of the OGC API — Coverages — Part 1: Core candidate Standard.

• Multiple conformance classes and recommendations of the OGC API — Processes — Part 1: Core Standard.

• Multiple versions of the Web Map Service (WMS), Web Processing Service (WPS), Web Map Tile Service (WMTS) and Web Feature Service (WFS) Standards.

• A number of other “un-adopted” OGC Web Service draft specifications including the Testbed-12 Web Integration Service, OWS-7 Engineering Report — GeoSynchronization Service, and the Web Object Service prototype.

The cubeserv executable supports a wide variety of back ends including Oracle, MariaDB, SHAPE files, etc. It also supports a wide array of service-dependent output formats (e.g., GML, GeoJSON, Mapbox Vector Tiles, MapMP, etc.) and coordinate reference systems.

4.4.7.  GNOSIS Map Server

The GNOSIS Map Server is written in the eC programming language and supports multiple OGC API Standards. GNOSIS Map Server supports multiple encodings including GNOSIS Map Tiles (which can contain either vector data, gridded coverages, imagery, point clouds or 3D meshes), Mapbox Vector Tiles, GeoJSON, GeoTIFF, GML and MapML. An experimental server is available online at https://maps.gnosis.earth/ogcapi and has been used in multiple OGC Innovation Program initiatives.

5.1.1.  OGC API — Records

The OGC API — Records team held two breakouts which focused on advancing the specification for OAB review.

Discussions included:

• target of December 2023 for OGC API — Records — Part 1: Core document submission for OAB

• issue sweep

• requirements refactoring (shared query parameters)

• resulting ATS refactoring

• update on templating links (allowing for using one of variables or varBase)

• clarification on …​/items q parameter

• cleanup and validation of example JSON documents; agreement to tidy up YAML schemas and build CI workflow to ensure schemas are always valid, a bundle is built, and examples are schema valid

• proposal for facets

• advertising facets and their types (options: separate endpoints, addition of facet: true properrites in (…​/queryables)

• specifying facets on …​/items requests

• agreement to review / approve proposal PR and move forward as an extension

• disussion on federation/distributed search

• how to address live / distributed search (without metadata harvesting/metadata aggregration)

• presents issues such as:

• how to present results (multipart, single document with ‘grouped’ records [would break GeoJSON interoperability])

• how to sort results

• this could be accomplished by a front end client (in Python or JavaScript, for example)

• some organizations want to provide a unified single catalogue that streamlines the search xperience for users

• could also be put forth as a best practice on implementation

• way forward is to put forth a proposal for discussion on requirements

5.1.2.  OGC API — Environmental Data Retrieval

5.1.3.  OGC Features and Geometries JSON

A free and open source json-fg-validator[https://github.com/tomkralidis/json-fg-validator] tool was created as an executable test suite to test JSON FG documents against the ETS requirements. The initial implementation provides a framework to test and report. The first pass covered most of the “Core” Requirements Class.

The tool is implemented in Python and contributions are welcome and encouraged.

5.1.4.  Geonovum testing of JSON-FG support in GDAL

Sprint participants from Geonovum worked on testing the JSON-FG candidate Standard and evaluating GDAL’s implementation of the candidate Standard. To facilitate the evaluation, they specified a series of test scenarios that includes tests of transformation of GML to JSON-FG, GeoPackage to JSON-FG and transformation from 3D data formats to JSON-FG. A more detailed discussion of the tests and their results is presented in an associated report [3]. Although the tests did not reveal any bugs nor issues found in GDAL’s support of JSON-FG, there were a number of findings that could inform future versions of GDAL.

The tests were applied to source data that contained features that were referenced to the Dutch coordinate reference system Rijksdriehoeks (RD). During transformation of feature data to JSON-FG, by default GDAL creates a geometry member that has coordinates that a referenced to WGS84. Further, also by default, GDAL creates a place member with coordinates obtained from the source data during transformation of feature data to JSON-FG. Although this conforms with the JSON-FG candidate Standard, it may not be what some users expect.

One of the findings was that when GDAL cannot identify a source property for the temporal information, it fills the time member of the JSON-FG file with a null value. There does not appear to a way to point GDAL at an appropriate source for filling the time member. However, as GDAL looks for an element called time, time_start, or time_end, it is possible to use a GDAL tool called ogr2ogr to remap the properties of the source data to an output property that has a name that GDAL expects (e.g. time). Another finding was that there is currently no apparent option to have GDAL create a JSON-FG file that references a JSON Schema file that describes the featureSchema.

5.1.5.  Example

TBA

5.2.1.  Towards open source libraries for GIMI

This section presents findings of the prototyping GIMI support in a selection of open source libraries. The prototyping and assessment was carried out by Brad Hards.

As a community we have an ecosystem that has some key dependencies that include GDAL + libheif, mp4box.js, rasterio, rio-tiler, pygeoapi etc. There are also some commercial libraries that sit alongside these open source libraries. GDAL is used by several applications such as GDAL. Rasterio is a very import tool. So the combination of tools and libraries presents a big stack is illustrated in Figure TBA. The sprint participants sought to show how this stack could be used to support GIMI.

Figure TBA shows a screenshot of an unmodified version of QGIS displaying two GIMI test files, overlayed on top of OpenStreetMap.

The sprint participants created a Jupyter Notebook, shown in Figure TBA, that used many of the aforementioned libraries to perform some data science analysis on GIMI imagery files.

Further work on pygeoapi involved importing a GIMI file into pygeoapi for serving through an interface conforming to OGC API – Coverages. This exposed coverage metadata as illustrated in Figure TBA.

Using the open source TiTiler toolkit, the sprint participants were able to partition GIMI test files into a tileset and to provision a pygeoapi instance with the tileset. This made it possible for the imagery to be accessible through an interface conforming to OGC API – Tiles and thus be displayed on an instance of OpenLayers.

In conclusion, the sprint participants found that there are a number of base libraries that are needed to improve the migration path for several applications. Amongst those base libraries are GDAL and libheif. Also needed are more tools, more examples of test data, and validators to facilitate the evaluation of test files.

5.2.2.  Example 2

TBA

5.3.1.  ldproxy

Sprint participants from interactive instruments worked on ldproxy’s support of a Publish/Subscribe (PubSub) capability for OGC API Standards. This included creation of a resource using the Topographic Data Store (TDS) schema of the NGA and enabling the resource to support PubSub as well as Create, Replace, Update, and Delete (CRUD) operations. The CRUD capabilities are described in an OpenAPI definition document and the PubSub capabilities are described in an AsyncAPI definition document. Links to both the OpenAPI and AsyncAPI definition documents are clearly visible on the landing page, as shown in Figure TBA.

Below is a fragment of the AsyncAPI definition document created to describe the supported PubSub capability. The fragment shows two of the thirty channels created for monitoring changes on feature collections provided by the API.

{
  "info" : {
    "title" : "Daraa",
    "description" : "This is a test dataset for the Open Portrayal Framework thread in the OGC Testbed-15 as well as for the OGC Vector Tiles Pilot Phase 2. The data is OpenStreetMap data from the region of Daraa, Syria, converted to the Topographic Data Store schema of NGA.",
    "version" : "1.0.0",
    "contact" : {
      "name" : "Clemens Portele, interactive instruments GmbH",
      "email" : "portele@interactive-instruments.de"
    },
    "license" : {
      "name" : "The dataset was provided by the US National Geospatial Intelligence Agency (NGA) for development and testing. For any reuse of the data outside this API, please contact NGA."
    }
  },
  "servers" : {
    "t19" : {
      "protocol" : "secure-mqtt",
      "protocolVersion" : "3.1.1",
      "url" : "t19.ldproxy.net:8883",
      "bindings" : {
        "clientId" : "cs2310.ldproxy.net",
        "cleanSession" : true,
        "bindingVersion" : "0.1.0"
      }
    }
  },
  "channels" : {
    "ogcapi/cs2310.ldproxy.net/daraa/collections/AeronauticCrv/items" : {
      "subscribe" : {
        "operationId" : "featureChange_AeronauticCrv_items",
        "bindings" : {
          "qos" : 0,
          "retain" : false,
          "bindingVersion" : "0.1.0"
        },
        "message" : {
          "$ref" : "#/components/messages/featureChange_AeronauticCrv"
        }
      },
      "servers" : [ "t19" ]
    },
    "ogcapi/cs2310.ldproxy.net/daraa/collections/AeronauticSrf/items" : {
      "subscribe" : {
        "operationId" : "featureChange_AeronauticSrf_items",
        "bindings" : {
          "qos" : 0,
          "retain" : false,
          "bindingVersion" : "0.1.0"
        },
        "message" : {
          "$ref" : "#/components/messages/featureChange_AeronauticSrf"
        }
      },
      "servers" : [ "t19" ]
    },

}

The team from interactive instruments also set up a broker for experimenting with the messages. The ldproxy instance offers access to approximately 30 different feature collections. Whenever something is created or changed in a feature collection, a message is sent to the broker. A screenshot showing the channels being monitored through an application called MQTT Explorer is presented in Figure TBA.

5.3.2.  OSGeo pycsw

The pycsw project upgraded support for the OGC API — Records q parameter based on the latest updates (PRs in https://github.com/geopython/pycsw/pull/912 https://github.com/geopython/pycsw/pull/913). In addition, record parsing and ingest updates and fixes were implemented given specification / schema updates.

5.3.3.  OSGeo pygeoapi

5.3.4.  Safe Software FME

5.3.5.  Example 3

TBA